#Innolight

当前方案只考虑从 Flash 启动，通过 Boot ROM 将整个程序拷贝到 IRAM 上执行（目前不考虑 Bootloader，升级通过 OTA 进行升级）。本文主要基于 Flash 的启动以及存储结构进行分析。

名词解释

启动设备

E3 MCU 支持以下启动设备：

• Nor/Hyper Flash
• eMMC
• SD Card
• USB/UART

芯片通过 Boot Mode Pin（启动模式引脚）的拨码配置来设置相应的启动流程。下表列出 e3_324_dev_kit 参考板使用的启动模式和对应 Boot Mode 拨码位置。

以下为从 Nor/Hyper Flash 模式时拨码开关的位置

以下为 Debug 模式时拨码开关的位置

存储器分布

在如上所示的典型 Flash 存储器分布图中，HyperFlash 的 Sector Size 大小为 256KB（典型值），Nor Flash 的 Sector Size 为 4KB（典型值）。为方便擦写，对 Flash 空间做如下分配：

• SFS 存储在 Sector 0 的 0x0 - 0x7F 区域内，占用 128 Bytes
• RFD 存储在 Sector 0 的 0xF0 - 0x1FF 区域内，占用 272 Bytes
• XSPI training 存储在预留的 Sector 1 区域
• Primary GPT 分区表存储在从 Sector 2 开始的区域内（非必须，仅预留），占用 17 KB 空间。Hyper Flash 仅需预留 1 个 Sector，Nor Flash 需预留 5 个 Sector。此外，根据 GPT 分区表的格式，还需要在 Flash 尾部预留 17 KB 空间存储分区表 Secondary 部分
• Boot Package 存储在其他 Sector 区域 ，由 BPT 和 Images 组成

SFS

SFS 包含 Flash 的配置信息以及 Boot Package 的存放地址，存储在 Flash 的起始位置。ROM 程序根据拨码识别到当前启动设备为 Flash 时，首先读取 Flash 中的 SFS 配置信息对 Flash 进行初始化，然后读取 Flash 中的 Boot Package 并完成启动。SFS 的配置详细参数表如下：

RFD

RFD 主要是用于加密启动，描述了加密启动的 Flash Region 的地址范围、密钥等信息。E3 的加密启动基于串行 Flash 控制器内嵌的运行时解密模块。加密启动具有如下特点：

• 支持 CPU 从 Flash 取指令或数据时实时解密，保证安全的同时不影响性能
• 支持 AES128 对称密码，提供足够的加密强度，Flash 的内容无法被破解
• 支持密钥烧写到芯片内部 eFuse 并锁定，锁定后仅对串行 Flash 控制器硬件可见，具有很高的安全等级

E3 系列芯片充分考虑了程序烧写到外部 Flash 的安全性。在自研的串行 Flash 控制 XSPI（支持 1/2/4/8 线，支持 SDR/DDR）中，加入了如下机制保证代码的安全性：

• 内嵌运行时加密模块，支持 CPU 在 Flash 取指令或数据时进行实时的解密，在保证安全的同时不影响性能
• 支持 AES128 对称密码，提供足够的加密等级，保证 Flash 的内容无法破解
• 用户密码烧写到芯片内部 eFuse 并可锁定。锁定后仅对 XSPI 硬件可见，对软件不可见。基于该功能，即使代码被恶意复制，因为复制者没有密钥，所以复制软件无法启动

XSPI 控制器支持数据解密功能。加密后的数据烧写 Flash 中（目前仅支持对 NOR Flash 解密），在配置了相应的信息后（RFD），软件可以直接从 XSPI 控制器读出解密后的明文，且这个过程对软件是透明的。E3 最多支持 4 个 RFD，一个 RFD 代表一个加密 Region，每个 RFD 大小是 64 Bytes，其格式如下图：

从如上框图可知：

• 每个 RFD 里设置了加密区域的起始和结束地址，从这个区域读出的数据会被硬件解密。这里的起始和结束都是指对 XSPI 控制器首地址的偏移
• 用户需要先对这个区域的数据进行加密，将密文写入对应区域
• RFD 只支持 PVK 模式解密
  • 使用 PVK0~PVK3 中的任意一个密钥对 IV 及 StartAddr~CFG 数据加密（支持 AES-128-CBC 模式）
  • 使用 PVK_X 和 IV 对此 Region 的数据进行加密（AES-128-CTR 模式）
  • RFD 中 KEK/IEK 会被忽略，填充了 0

Boot Package

Boot Package 中包含各个核的用户程序，如果 ROM 程序对其校验通过则将其作为下一级启动镜像进行启动。Boot Package 分为三种类型，它们互为冗余：

• Normal Boot Package
• Backup Boot Package
• Third Try Boot Package

Boot Package 地址由 SFS 指定，默认按照预留分区表的方式划分，存储地址如下：

按照 XSPI 控制器在 MCU 中的地址映射，不同类型的 Boot Package 在 MCU 地址空间里的地址为：

因为每个 Boot Package 的从起始地址开始的 4096 字节是 BPT，因此镜像组合的起始地址需要在 Boot Package 的地址映射基础上加上 0x1000。

BPT

BPT 位于 Boot Package 最前端，共占用 4096（0x1000）个字节，包括以下信息：

• Boot Package 的签名信息
• 各个镜像在 Image 组合中的相对位置（DLP）
• 镜像加载地址（Load Address）
• 镜像运行时入口地址（Entry）
• HASH 校验信息
• PSN 信息

Images

Images 是多个核的用户程序镜像组合，包含：

• Bootloader 镜像
• SCB 程序控制块
• CPU Cluster0 程序镜像
• CPU Cluster1 程序镜像（可配置为 Split 或者 Lockstep）
• CPU Cluster2 程序镜像（可配置为 Split 或者 Lockstep）

启动流程

芯片 POR 复位后，当启动核（CPU Cluster0 Core）从复位状态退出时，集成于芯片内部的 ROM 程序在启动核中开始运行，以完成芯片的启动过程。ROM 程序具有以下特点：

1. ROM 程序根据启动模式引脚，从不同启动设备启动
2. ROM 程序支持从 Flash 中读取 SFS 配置信息对 Flash 初始化
3. ROM 程序支持从 Flash 中读取 RFD 配置信息实现加密启动
4. ROM 程序支持对 Boot Package 验签，以确保各个 Core 依次安全启动
5. ROM 程序支持从多个 Boot Package 启动

因此在编译完固件之后，需要完成以下步骤来满足 Flash 启动流程：

1. 将编译得到的各个 Core 的固件合并后签名，得到 Boot Package 文件
2. 根据 Flash 配置信息生成 SFS 文件
3. 根据 Flash Region 和密钥等信息生成 RFD 文件（可选）
4. 将上述三种文件打包在一个 PAC 文件中，使用 SemiDrive 下载工具完成烧写

以下分别介绍两种常见的启动模式：

• 直接启动：ROM 直接加载和启动各 CPU Cluster 的用户程序
• 多级启动：ROM 只加载和启动 CPU Cluster0 的 Bootloader 镜像，后者负责加载启动各 CPU Cluster 的用户程序

直接启动

直接启动模式只支持将用户程序程序加载到 IRAM 中运行，不支持从 ROM 直接跳转到 Flash 上 XIP 运行，原因是 XIP 运行前需要对 XSPI 控制器执行 DLL override mode training，training 动作不能在 XIP 运行时执行。

ROM 默认先启动 Image 组合中的 CPU Cluster1/CPU Cluster2，也可以配置为只加载 CPU Cluster1/CPU Cluster2 程序到 IRAM，但不启动 CPU Cluster1/2，最后 ROM 将 CPU Cluster0 启动。

多级启动

多级启动模式下 Boot Package 中只打包一个 image，即 CPU Cluster0 Bootloader（Bootloader 程序由客户自行开发）。多级启动模式支持将用户程序运行在 IRAM 中，或者 XIP 运行，基本流程是：

1. 上电后 ROM 将 CPU Cluster0 Bootloader 加载到 IRAM，然后跳转过去执行
2. 如果用户程序以 XIP 模式运行，CPU Cluster0 Bootloader 需要执行 XSPI training
3. Bootloader 加载 CPU Cluster 0/1/2 的用户程序
4. Bootloader 启动 CPU Cluster1/2，然后跳转到 Cluster0 用户程序

如果选择 XIP 运行，需要在 Bootloader 中调用驱动完成对 XSPI DLL override mode training 与其他初始化。当 XIP 程序链接地址为 0 时，XIP 程序的大小需要在 4MB 内；当 XIP 程序链接地址与 XIP 程序存储地址一致时，XIP 程序的大小无限制。目前 E3 SSDK 中 XIP demo 全部使用 XIP 程序链接地址与 XIP 程序存储地址一致的方案。

打包流程

打包的目的是：

1. 将编译产物 BIN 文件转换为 Boot Package 格式。ROM 启动时需要识别这种格式的文件。
2. 将 Boot Package 形成 PAC 文件用于下载工具烧录。PAC 文件中包含了 Flashloader 和 SFS 等其他需要烧录或参与烧录过程的文件。

基于 Flash 打包的 PAC 文件包含以下部分：

• FDA.img：这里称为 Downloader 程序。该程序仅下载时存在于 IRAM，不占用系统的存储空间。拨码至 JTAG 模式上电，工具将 Flashloader 程序加载到 IRAM 中，然后调用 Flashloader 中的函数将各个 Boot Package、SFS 和 RFD 文件写入到存储设备中。Flashloader 不支持使用分区表的 PAC 包下载。
• SFS.img：仅存在于 Nor/Hyper Flash 的 PAC 包中，用于存储 Flash 信息，仅供 ROM 启动时读取
• RFD.img：仅存在于 Nor/Hyper Flash 的 PAC 包中，用于从 Flash 加密启动
• 用户也可以在打包过程中以地址的形式加入用户的固件，在下载时能够将其下载到该地址中

手动打包

1. 签名形成 Boot Package

编译得到 binary 产物之后，使用 atb_signer 工具可以把编译产物转换为 Boot Package 文件。在该过程中，atb_signer 工具会在 BPT 中生成各个镜像在 Image 组合中的相对位置，镜像 Load 地址，Entry 地址，Hash 校验信息，PSN 信息，以及签名信息，并且把编译产物排列为镜像组合放在 BPT 之后。

sign_tool\windows\atb_signer.exe sign --v 2 --sec_ver 0 --dgst
sha256 --rcp key=sign_tool\keys\TestRSA2048_ossl.pem ^
--iib core=0 type=0x0 image=temp\sf.bin dlp=0x8 to=0x404000
entry=0x404000 ^
--iib core=2 type=0x0 image=temp\sp0.bin dlp=0x100 to=0x600000
entry=0x600000 ^
--iib core=3 type=0x0 image=temp\sp1.bin dlp=0x200 to=0x680000
entry=0x680000 ^
--iib core=4 type=0x0 image=temp\sx0.bin dlp=0x300 to=0x500000
entry=0x500000 ^
--iib core=5 type=0x0 image=temp\sx1.bin dlp=0x400 to=0x580000
entry=0x580000 ^
--psn 0x100 --of temp\ssdk_signed_normal.bin

上述命令的参数解析如下表：

上述步骤结束后，最终得到的 Boot Package 文件的路径为：

ssdk\tools\sdtools\temp\ssdk_signed_normal.bin

按照上述命令我们可以依次打包得到 Backup Boot Package 和 Third Try Boot Package。

2. 打包形成 PAC 文件

该过程会把 Boot Package 文件与 SFS 等文件打包成 PAC 文件，用于 USB 或 JTAG/SWD 下载。

# 进入工具所在路径
cd tools\sdtools\

# 根据 SFS 的配置文件以及分配的 Boot Package 地址形成 SFS 文件，以型号 Cypress 的 Flash 为例生成 SFS 文件
..\..\prebuilts\windows\python-3.7.0\python.exe
pactool\gen_sfs_binary.py
--json sfs\s26h-hyperFlash.json
--out temp\sfs.img
--normal_img_off 0xC0000
--backup_img_off 0x4C0000
--third_img_off 0x8C0000

# 生成 Dloader/Flashloader，工程路径下提供了预编译好的 bianry 文件，拷贝出来直接即可
sign_tool\windows\atb_signer.exe sign --v 2 --sec_ver 0
--dgst sha256 --rcp key=sign_tool\keys\TestRSA2048_ossl.pem
--iib core=0 type=0x0 image=temp\downloader_e3_gateway.bin
to=0x404000 entry=0x404000
--psn 0x01 --of temp\downloader_e3_gateway_signed.bin

# 在 ssdk\tools\sdtools\temp 路径下包含 ssdk_signed_normal.bin ssdk_signed_backup.bin ssdk_signed_thrid.bin sfs.img sf.bin downloader_e3_gateway_signed.bin 文件后执行打包命令就会在 pac\e3_gateway\boot_core\emmc_e3_gateway.pac 路径下生成 pac 文件
pactool\pactool make_pac_image_no_gpt
--output pac\e3_gateway\boot_core\ospi_e3_gateway.pac
--allow_empty_partitions
--da FDA:temp\downloader_e3_gateway_signed.bin
--preload sfs:temp\sfs.img
--preload rfd:rfd\xspi_wrap_rfd_blk_pvk1_ks.rfd
--preload boot0:temp\ssdk_signed_normal.bin
--preload boot1:temp\ssdk_signed_backup.bin
--preload boot2:temp\ssdk_signed_third.bin

自动打包

利用自动打包脚本 tool/genpac.py 可以完成自动打包流程。genpac.py 可以解析项目的打包配置文件 pac_config.json 进行打包，可以自动完成：

1. 将编译产物 binary 合成 Boot Package
2. 选择 SFS 的配置文件，将配置文件转换为 SFS.img 用于打包，同时能够指定 Boot Package 的地址
3. 选择打包 Dloader 或 Flashloader，对 Dloader 进行签名，Flashloader 不签名
4. 可以进行加密配置
5. 形成 SDFactoryTool 软件烧录所需的 PAC 文件

"board": "e3_gateway",
"project": "ref",
"sf_path": "tools\genpac\sf.bin", //示例路径，用户可自行指定绝对路径
"sp0_path": "tools\genpac\sp0.bin", //示例路径，用户可自行指定绝对路径
"sp1_path": "tools\genpac\sp1.bin", //示例路径，用户可自行指定绝对路径
"sx0_path": "tools\genpac\sx0.bin", //示例路径，用户可自行指定绝对路径
"sx1_path": "tools\genpac\sx1.bin", //示例路径，用户可自行指定绝对路径
"downloader_path": "tools\genpac\dloader.bin",
//示例路径，用户可自行指定绝对路径

升级流程

OTA 全称为 Over-The-Air Technology（空中下载技术），是指通过移动通信的接口实现对软件进行远程管理和升级。

OTA 升级过程一般包含四个目标，详见下表说明：

• 无感升级：能同时满足以上 1~3 OTA 升级目标的升级方式
• 有感升级：无法同时满足以上 1~3 OTA 升级目标的升级方式

芯驰 E3 MCU OTA 升级方案支持基于 IRAM 和 XIP 完成升级，也称非 XIP 升级方式和 XIP 升级方式。

• 非 XIP 方式（IRAM 方式）：程序运行在 IRAM 中，在程序运行过程中，可以对存储器进行擦写操作
• XIP 方式：程序运行在 Flash 中，在程序运行过程中，无法同时对所在的 Flash 进行擦写操作。

两种升级方式所支持的功能见下表：

ALL-By-ROM 启动

• 静默升级：当 Boot Package A 启动时，程序运行在 IRAM 中，此时可以对 Boot Package B 或者 Boot Package C 进行擦写，并将 PSN 号更新到最大
• 无缝切换：ROM 自动选择 PSN 比较大的 Boot Package 启动，无需等待时间
• 回滚：通过烧写 Fuse，上电默认开启 WDT 看门狗功能，使能看门狗动作复位后或主动复位切换到 ROM 的 Bootloader 功能。需要在打包时增加一个 Bootloader 程序到 Boot Package 中，该 Bootloader 可以理解为 recovery 程序，仅在回滚时使用，正常启动时不进入。如果 OTA 升级后启动失败，则进入 recovery 程序，在该模式中擦除新升级的 Boot Package 程序，下次启动从旧的 Boot Package 中启动
• 安全启动：采用 Semidrive 的签名和加密方案

SF-Only 启动

• 静默升级：SF 本身的升级策略：当 Boot Package A 启动时，程序运行在 IRAM 中，此时可以对 Boot Package B 或者 Boot Package C 进行擦写，并将 PSN 号更新到最大。SF 启动后其他镜像的升级策略：将其他镜像的分区划分为 A/B 分区，通过设置分区的 flag，判断当前的活动分区，在启动加载时 SF 自动选择活动的分区进行加载。
• 无缝切换：SF 根据 PSN 版本比较大的启动；其他 Core 选择 Active 的分区进行加载，无需等待升级。
• 回滚：SF 本身的回滚策略，可以按照 ALL-by-ROM 启动的回滚流程，进入 recovery 程序来进行回滚。其他 Core 的回滚策略，可通过 SF 来判断其他 Core 升级后是否正常运行，如果运行异常可通过设置 A/B 分区 flag，将当前分区的属性切换为非活动，之后依然从原分区启动。
• 安全启动：采用 Semidrive 的签名和加密方案，其他镜像的安全启动策略需要用户定制。

烧录调试

以下基于存储设备是 Flash 的情况，梳理以下烧录和调试的流程：

1. 如果是调试阶段，程序可以直接烧录到 IRAM 中运行，无需打包成 PAC 格式，重启后 IRAM 中的内容会丢失。
2. 如果是正式阶段，程序需烧录到 Flash 中，但是执行的模式分为两种，IRAM 和 XIP 运行。XIP 模式下程序被分为 Bootloader 和 App 两部分。Bootloader 运行于 IRAM 上，可以直接擦写 Flash，之后跳转到 App 中 XIP 运行，无法对存储设备（仅 Nor/Hyer Flash 支持 XIP 运行）进行擦写。程序烧录到 Flash 模式下，无论是 IRAM 还是 XIP 运行，都需要烧录 PAC 包，因为 ROM 启动阶段只识别 PAC 格式的包。

XIP 运行前需要对 XSPI 控制器执行 DLL override mode training，training 动作不能在 XIP 运行时执行。所以才需要分为 Bootloader 和 App 两部分。这里可以结合启动流程的直接启动和多级启动的差异部分去理解。